MacTech 1 to 12/MacTech-vol-1-12.toast/Reference/the cmsp digests ('94-'97)/csmp digest Vol 3 No 102

Text File | 1995-07-01 | 110KB | 2,829 lines

C.S.M.P. Digest             Sat, 01 Jul 95       Volume 3 : Issue 102

Today's Topics:

        AE source --> address descriptor (?)
        AESetData events to Finder
        Are AppleEvents efficient?
        COMP.LANG.PASCAL.MAC - New Macintosh Pascal language newsgroup
        Changing current printer without user intervention
        Error checking calls to NewRgn & GetClip
        GWorlds-CopyBits
        Getting the selected portion of an editText item
        Licensing the PEF format: the answer
        MacTCP and Native code
        MacTech vs. develop
        MacsBug Docs? (was Re: Where are the @$# keyUp events?!!)
        Overwhelmed newbie needs encouragement
        Time manager callback without asm?
        TransSkel 3.21 is available (MW Pascal support added)
        Uppercase Command Keys?
        [Q] Drag and Drop Mgr hilighting
        [Q] How to tell if a hard disk is removable



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroups
comp.sys.mac.programmer.help, csmp.tools and csmp.misc. It is designed for
people who read news semi-regularly and want an archive of the discussions.
If you don't know what a newsgroup is, you probably don't have access to
it. Ask your systems administrator(s) for details. If you don't have access
to news, you may still be able to post messages to the group by using a
mail server like anon.penet.fi (mail [e-mail] for more
information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                                Sends you a summary of commands
    subscribe csmp-digest Your Name     Adds you to the mailing list
    signoff csmp-digest                 Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail].

-------------------------------------------------------

>From [e-mail] (Eric Kofoid)
Subject: AE source --> address descriptor (?)
Date: Thu, 01 Jun 1995 11:16:02 -0700
Organization: Dept. Biology, University of Utah

My program receives an AppleEvent from another application, and extracts
its keyEventSourceAttr attribute. How can it convert this into an address
descriptor record to communicate efficiently with the original sender?
...or is there a better way to find the return address?

Cheers,

Eric.
==========
Dept.Biology, U.of Utah

+++++++++++++++++++++++++++

>From [e-mail] (Brian Stern)
Date: 8 Jun 1995 03:39:57 GMT
Organization: The University of Texas at Austin, Austin, Texas

In article <[e-mail]>,
[e-mail] (Eric Kofoid) wrote:

< My program receives an AppleEvent from another application, and extracts
< its keyEventSourceAttr attribute. How can it convert this into an address
< descriptor record to communicate efficiently with the original sender?
< ...or is there a better way to find the return address?
<
< Cheers,
<
< Eric.
< ==========
< Dept.Biology, U.of Utah

The return address is in the keyAddressAttr.  Here is some code that I use
to build an AEDesc for a return address:

// ---------------------------------------------------------------------------
//
// ---------------------------------------------------------------------------
// Extract the sessionID from the appleevent.  There will either be a
// sessionID or a TargetID that has a sessionID inside it.

void
GetSessionID( const AppleEvent &inAppleEvent )
{
   TargetID    theTarget;
   DescType    theType;
   Size        theSize;

   OSErr err = ::AEGetAttributePtr( &inAppleEvent, keyAddressAttr,
               typeTargetID, &theType, &theTarget, sizeof(TargetID), &theSize );

   if ( err == errAECoercionFail )
   {
      err = ::AEGetAttributePtr( &inAppleEvent, keyAddressAttr,
            typeSessionID, &theType, &theTarget.sessionID,
sizeof(PPCSessRefNum),
             &theSize );
   }

   ThrowIfOSErr_(err);

   err = ::AECreateDesc( typeSessionID, &theTarget.sessionID,
sizeof(PPCSessRefNum),
            &mClientDesc );
   ThrowIfOSErr_(err);

   mClientSessionID = theTarget.sessionID;   // Save the sessionID

}

____________________________________________________________________
Brian  Stern  {:-{)}                          [e-mail]
Toolbox commando and Menu bard.             Will FlushCache for Cash

+++++++++++++++++++++++++++

>From [e-mail] (Grobbins)
Date: Thu, 08 Jun 1995 10:20:40 -0700
Organization: Skunkworks

In article <[e-mail]>,
[e-mail] (Eric Kofoid) wrote:
>My program receives an AppleEvent from another application, and extracts
>its keyEventSourceAttr attribute. How can it convert this into an address
>descriptor record to communicate efficiently with the original sender?
>...or is there a better way to find the return address?

A quick search through the tech notes reveals this old bit from note IC
505 - Apple Event Manager Q&As:


- -
Finding Apple event sender9s target ID or process serial number
Date Written:  10/25/91
Last reviewed:  6/14/93
How can I identify the sender of an Apple event?
___
If your application is just sending a reply, it should not be creating an
Apple event or calling AESend. Instead, the Apple event handler should
stuff the response information into the reply event, as shown on page 6-50
of Inside Macintosh Volume VI. The Apple Event Manager takes care of
addressing and sending the event.

To find the target ID or process serial number of the sender of an Apple
event, use AEGetAttributePtr to extract the address attribute, as follows:

retCode := AEGetAttributePtr(myAppleEvent, keyAddressAttr,
                typeWildCard, senderType, @senderBuffer,
                sizeof(senderBuffer), senderSize)

The senderBuffer can later be used with AECreateDesc to create an address
to be passed to AESend. The buffer should be at least as large as data
type TargetID. See Inside Macintosh Volume VI, page 5-22, for a
description of TargetID.
- -


Since the attribute is unknown size, it's probably easier to extract it
with AEGetAttributeDesc.

Grobbins                                   [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Ed Lai)
Date: Sat, 17 Jun 1995 01:21:40 GMT
Organization: Apple

In article <[e-mail]>,
[e-mail] (Eric Kofoid) wrote:

> My program receives an AppleEvent from another application, and extracts
> its keyEventSourceAttr attribute. How can it convert this into an address
> descriptor record to communicate efficiently with the original sender?
> ...or is there a better way to find the return address?
>
> Cheers,
>
> Eric.
> ==========
> Dept.Biology, U.of Utah

Event source means whether it is from same process, same machine or
remote machine.

To find where it comes from, use the 'addr' attribute.

--
/* Disclaimer: All statments and opinions expressed are my own */
/* Edmund K. Lai                                               */
/* Apple Computer, MS303-3A                                    */
/* 20525 Mariani Ave,                                          */
/* Cupertino, CA 95014                                         */
/* [phone]                                               */
zW@h9cOi

---------------------------

>From Carl R. Osterwald <[e-mail]>
Subject: AESetData events to Finder
Date: 9 Jun 1995 21:53:37 GMT
Organization: National Renewable Energy Laboratory

Given a file as an FSSpec, I need to build object specifier record that
points to the file's icon bitmap, in order to give the file a custom
icon with a Set Data event to the scriptable Finder.  I have been
following the code in the develop 20 article that describes the
scriptable Finder, but the example give there just sends an empty
bitmap list to the object currently selected, rather than to an FSSpec.
How should I create the object specifier for the keyDirectObject portion
of the event in this case?

I have tried using the special key form mentioned in the article,
formAlias, but this did not work:
- -----------------------------
   error = AECreateDesc(typeNull, nil, 0, &null_descriptor);

   error = NewAliasMinimal(&file_spec, &file_alias);

   HLock( (Handle)file_alias );

   error = AECreateDesc( typeAlias, *file_alias,
             GetHandleSize( (Handle)file_alias ),
             &alias_descriptor);

   DisposeHandle( (Handle)file_alias );

   error = CreateObjSpecifier( typeWildCard, &null_descriptor,
             formAlias, &alias_descriptor,
             true, &file_specifier);

   DescType property = pIconBitmap;

   error = AECreateDesc( typeType, (Ptr)&property,
             sizeof(DescType),
             &icon_property);

   error = CreateObjSpecifier( cProperty, &file_specifier,
             formPropertyID, &icon_property,
             true, &icon_specifier);

   error = AEPutParamDesc( &event,
             keyDirectObject,
             &icon_specifier);

   AEDisposeDesc(&icon_specifier);


   error = AECreateList(nil, 0, make_AERecord, &icon_family);


   error = AEPutKeyPtr( &icon_family, keyIconAndMask,
             typeIconAndMask,
             ICN_, GetPtrSize(ICN_) );

   error = AEPutKeyPtr( &icon_family, key8BitIcon,
             type8BitIcon,
             icl8, GetPtrSize(icl8) );

   error = AEPutKeyPtr( &icon_family, key4BitIcon,
             type4BitIcon,
             icl4, GetPtrSize(icl4) );

   error = AEPutKeyPtr( &icon_family, keySmallIconAndMask,
             typeSmallIconAndMask,
             ics_, GetPtrSize(ics_) );

   error = AEPutKeyPtr( &icon_family, keySmall8BitIcon,
             typeSmall8BitIcon,
             ics8, GetPtrSize(ics8) );

   error = AEPutKeyPtr( &icon_family, keySmall4BitIcon,
             typeSmall4BitIcon,
             ics4, GetPtrSize(ics4) );

   error = AEPutParamDesc(&event, keyAEData, &icon_family);

   AEDisposeDesc(&icon_family);

   error = AESend( &event, &reply, kAEWaitReply,
             kAEHighPriority,  kAEDefaultTimeout,
             (AEIdleUPP)AE_idle_function, nil);

result: -10001 errAETypeError
- -----------------------------

I have sucessfully sent update events to the Finder, so I know
the rest of the code for addressing the events is working.

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Sat, 10 Jun 1995 15:13:30 -0700
Organization: Internet for the Olympic Peninsula

In article <3raft1$[e-mail]>, Carl R. Osterwald
<[e-mail]> wrote:

> Given a file as an FSSpec, I need to build object specifier record that
> points to the file's icon bitmap, in order to give the file a custom
> icon with a Set Data event to the scriptable Finder.  I have been
> following the code in the develop 20 article that describes the
> scriptable Finder, but the example give there just sends an empty
> bitmap list to the object currently selected, rather than to an FSSpec.
> How should I create the object specifier for the keyDirectObject portion
> of the event in this case?

Just use AEPutParamPtr() to make the keyDirectObject parameter a copy of
the FSSpec struct, using type typeFSS.  Scriptable Finder will accept a
typeAlias or typeFSS in places where it pretends it wants one of its
object specifiers specifying a file.

  --John (yes, I didn't read the rest of the function in detail)

--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
       I don't do windows.
   [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Grobbins)
Date: Sun, 11 Jun 1995 02:39:21 -0700
Organization: Skunkworks

In article <3raft1$[e-mail]>, Carl R. Osterwald
<[e-mail]> wrote:
>Given a file as an FSSpec, I need to build object specifier record that
>points to the file's icon bitmap, in order to give the file a custom
>icon with a Set Data event to the scriptable Finder.  I have been
>following the code in the develop 20 article that describes the
>scriptable Finder, but the example give there just sends an empty
>bitmap list to the object currently selected, rather than to an FSSpec.

The posted direct object code looks pretty good; best way to test it is to
do a GetData instead of a SetData.

Unfortunately, the Finder is a little weird about icon bitmaps.  It'll
take an empty list to clear an icon, but what it wants as keyAEData to set
an icon is the icon data in an AERecord that has been manually coerced to
a typeIconFamily ('ifam').  The keywords and typecodes for the parameters
of the AERecord should both be the icon resource types (like 'ics8').


Grobbins                         [e-mail]

+++++++++++++++++++++++++++

>From Carl R. Osterwald <[e-mail]>
Date: 12 Jun 1995 16:44:09 GMT
Organization: National Renewable Energy Laboratory

In article <[e-mail]> John W.
Baxter, [e-mail] writes:
>Just use AEPutParamPtr() to make the keyDirectObject parameter a copy of
>the FSSpec struct, using type typeFSS.  Scriptable Finder will accept a
>typeAlias or typeFSS in places where it pretends it wants one of its
>object specifiers specifying a file.

Yes, this is true.  For the Update event, all you need is an FSSpec in
the keyDirectObject.  However, for the Set Data event, the
keyDirectObject needs to indicate the object being set, e.g. the icon
bitmap.  So I think an object specifier is required in this case.

In article <[e-mail]> Grobbins,
[e-mail] writes:
>The posted direct object code looks pretty good; best way to test it is to
>do a GetData instead of a SetData.

Thanks, I'll poke around with the Get Data event.

>Unfortunately, the Finder is a little weird about icon bitmaps.  It'll
>take an empty list to clear an icon, but what it wants as keyAEData to set
>an icon is the icon data in an AERecord that has been manually coerced to
>a typeIconFamily ('ifam').

I didn't do a manual coercion of the AERecord to typeIconFamily, I'll
try it out.

>The keywords and typecodes for the parameters
>of the AERecord should both be the icon resource types (like 'ics8').

I included <FinderRegistry.h> from the develop 20 article which makes
these definitions.

---------------------------

>From Jamie Uther <[e-mail]>
Subject: Are AppleEvents efficient?
Date: 13 Jun 1995 11:51:05 GMT
Organization: The Greenhouse, Dept. of Comp. Sci, Sydney University

Just how slow and resource-hungry are appleEvents? If i were to
write an application as a bunch of modules communicating
via appleEvents (like openDoc?) would i be getting into
trouble? I assume they're slower than shared memory,
but are they slower than RPC? How much slower? How do
they fit in with SOM and other message passing schemes?

this enquiring mind wants to know! so does anyone have
any hard knowledge about this?

thanks
        jim
        [e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Tue, 13 Jun 1995 10:05:54 -0700
Organization: Internet for the Olympic Peninsula

In article <3rju39$[e-mail]>, Jamie Uther <[e-mail]> wrote:

> Just how slow and resource-hungry are appleEvents? If i were to
> write an application as a bunch of modules communicating
> via appleEvents (like openDoc?) would i be getting into
> trouble? I assume they're slower than shared memory,
> but are they slower than RPC? How much slower? How do
> they fit in with SOM and other message passing schemes?

If the Apple event passes from process (in the Process Manager sense) to
process, it is "fairly slow" (the system seems to manage about 30 per
second on reasonable hardware).  If it is sent on a queued basis within a
process, it is less slow.  If the event is a "send-to-self" event (address
is specifically a PSN of kCurrentProcess), it is essentially a somewhat
slow function call (that is, very much faster than the other cases).  The
send-to-self case is "fast enough" to be used for things like responding
to UI actions without appearing slower to the user than direct funtion
calls used to be.

Sorry...nothing quantitative.

You can also produce a fairly fast interprocess event:  send it by
send-to-self, but self doesn't handle it.  The target has installed a
System event handler for the event, and handles it.  The target code has
to be quite careful:  it is running as an intruder in the caller's space.
No screen updating, and various other things.  One form of Frontier
menusharing uses this, as does UserLand's little "uBASE" database.  These
sends are "very much faster" than normal interprocess sends.  They are
also tricky to code the handlers for, and tricky to debug.

    --John

--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
       I don't do windows.
   [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Mike Cohen)
Date: Tue, 13 Jun 1995 20:37:25 GMT
Organization: ISIS International

[e-mail] (John W. Baxter) writes:

>If the Apple event passes from process (in the Process Manager sense) to
>process, it is "fairly slow" (the system seems to manage about 30 per
>second on reasonable hardware).  If it is sent on a queued basis within a
>process, it is less slow.  If the event is a "send-to-self" event (address
>is specifically a PSN of kCurrentProcess), it is essentially a somewhat
>slow function call (that is, very much faster than the other cases).  The
>send-to-self case is "fast enough" to be used for things like responding
>to UI actions without appearing slower to the user than direct funtion
>calls used to be.

According to Apple at WWDC, AppleEvent performace will be much faster in
Copland & AppleEvents still remain the preferred IPC method.
--
Mike Cohen - [e-mail]
Home Page: ftp://ftp.netcom.com/pub/is/isis/home.html
PUSH THE BUTTON... SOMEONE

+++++++++++++++++++++++++++

>From [e-mail] (Adam Winer)
Date: Tue, 13 Jun 1995 17:30:46 -0800
Organization: Oracle Corp.

In article <3rju39$[e-mail]>, Jamie Uther <[e-mail]> wrote:

>Just how slow and resource-hungry are appleEvents? If i were to
>write an application as a bunch of modules communicating
>via appleEvents (like openDoc?) would i be getting into
>trouble? I assume they're slower than shared memory,
>but are they slower than RPC? How much slower? How do
>they fit in with SOM and other message passing schemes?
>
>this enquiring mind wants to know! so does anyone have
>any hard knowledge about this?

Simple answer: now, kinda slow and inefficient.  In
Copland, stinkin' fast.  The current Copland benchmark
is something like 150,000 Apple Events a second.
--
Adam Winer
[e-mail]

---------------------------

>From [e-mail] (Scott A. Moore)
Subject: COMP.LANG.PASCAL.MAC - New Macintosh Pascal language newsgroup
Date: 13 Jun 1995 17:10:06 -0500
Organization: CCnet Communications (510-988-7140 guest)

A new newsgroup has been created exclusively for Pascals on the Macintosh,
including Apple Pascal, Think Pascal, CodeWarrior and others. This will
finally give Mac Pascal programmers a place to discuss Pascal implementation
on the Macintosh without being mixed in with other Pascals or the C language.
The new group was named:

     comp.lang.pascal.mac

and was created today, June 12, 1994 (if the group has not been created on
your news-host, you may want to contact your news-admin and request the group)

                                           [sam]



---------------------------

>From [e-mail] (Ian Dobson)
Subject: Changing current printer without user intervention
Date: Tue, 06 Jun 1995 20:53:25 +1000
Organization: NetSpace Online Systems

My company has recently purchased a dedicated label printer for printing
mailing labels. We are running a moderately complicated programmable
database system to store client records and maintain accounts.

Currently it is a pain in the ass for users to print labels, because they
have to go to Chooser, select the label printer, print the label, go back
to Chooser and select the LaserWriter (for normal output) again.

Now, please don't flame me for heresy, but is there any way to program
around this process so that the users can just choose a command "print a
label" from our database system (OMNIS, but can be customized with C
extensions etc.) and it will go the right way?

It's been a long time since I delved into this type of problem but last
time I looked this was the sort of thing that Apple thought police locked
you up for asking. Why, I ask? The ability to select a printer
automatically here would improve the user interface from our perspective
and save us a lot of time.

If there are no ways of doing this safely by circumventing the Chooser,
can the Chooser be controlled with Apple Events / AppleScript and if so
then how?

Please direct any response to e-mail ([e-mail]) because I don't
read this group very often and our newsserver is kind of flaky about
getting all the return mail at the moment.

TIA

--
Ian R. Dobson
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (PandH Phot)
Date: 6 Jun 1995 17:53:43 -0400
Organization: America Online, Inc. (1-800-827-6364)

I have a routine I've used for some time which RETURNS the name of the
currently-selected printer. I suppose a daring person could try to modify
it to SET the name, as well. Here's how it works:

1) Get the name of the currently-selected printer driver by calling
GetString on resource ID -8192. This string resource resides in the System
and tracks, well, the current printer driver. I should warn you that Apple
has specifically told me that this is undocumented and not guaranteed to
be forever cool.

2) Get a dirID to the current Extensions folder using FindFolder and the
following contants: kOnSystemDisk,  kExtensionFolderType,
kDontCreateFolder.

3) Using the file name (same as driver name) from step 1 and the dirID
from step 2, open the printer driver using FSpOpenResFile.

4) Get resource type 'PAPA', ID -8192, from the newly-opened resource
file. The first pascal string in the PAPA resource appears to always
contain the currently-selected printer's name.

Hope this helps

Paul

+++++++++++++++++++++++++++

>From [e-mail] (Tom Dowdy)
Date: Wed, 7 Jun 1995 15:28:03 GMT
Organization: Apple Computer, Inc.

In article <3r2ip7$[e-mail]>, [e-mail] (PandH
Phot) wrote:

> I have a routine I've used for some time which RETURNS the name of the
> currently-selected printer. I suppose a daring person could try to modify
> it to SET the name, as well. Here's how it works:
>
> 1) Get the name of the currently-selected printer driver by calling
> GetString on resource ID -8192. This string resource resides in the System
> and tracks, well, the current printer driver. I should warn you that Apple
> has specifically told me that this is undocumented and not guaranteed to
> be forever cool.

And specifically, that forever is now.  On machines running QuickDraw
GX, both the string for the current printer, and the information
you "document" below for changing the "current printer string"
do not work.

Applications which use GX can change the printer that is assigned
to a particular document they have open via a publically documented
and supported API.

--
 Tom Dowdy                  Internet: [e-mail]
 Apple Computer MS:302-3KS  UUCP: {sun,voder,amdahl,decwrl}!apple!dowdy
 1 Infinite Loop            AppleLink: DOWDY1
 Cupertino, CA 95014
 "The 'Ooh-Ah' Bird is so called because it lays square eggs."

+++++++++++++++++++++++++++

>From [e-mail] (Lawrence D9Oliveiro)
Date: Thu, 08 Jun 1995 17:35:04 +1200
Organization: University of Waikato

In article <3r2ip7$[e-mail]>, [e-mail] (PandH
Phot) wrote:

>1) Get the name of the currently-selected printer driver by calling
>GetString on resource ID -8192. This string resource resides in the System
>and tracks, well, the current printer driver. I should warn you that Apple
>has specifically told me that this is undocumented and not guaranteed to
>be forever cool.

It breaks with people using QuickDraw GX (as I am); under GX, this string
holds the name of the default desktop printer.

---------------------------

>From [e-mail] (Squeegee)
Subject: Error checking calls to NewRgn & GetClip
Date: Wed, 07 Jun 1995 14:59:59 -0400
Organization: SQ Software

[ Note:  In composing my message, I answered my own question.  I figured
  I'd post it anyway so I can be corrected if I'm wrong, and because
  maybe someone will benefit from reading it.  The answer is that it's
  probably best not to error check these functions (there's really no
  great way to do it anyway) and have a GrowZoneProc which manages a
  small amount of reserve memory to guarantee that these functions don't
  fail due to lack of memory.  See TCL or MacApp or PowerPlant for
  examples of GrowZoneProc management. ]

Safe code experts,

I was reviewing some code I had written and came across some code
similar to this example from Think Reference:

        saveClipRgn = NewRgn();         /* get an empty region */
        GetClip( saveClipRgn );         /* save current */
        SetClip( myClipRgn );           /* install desired clipRgn */

        /*... ( draw a figure )  ... */

        SetClip( saveClipRgn );         /* restore previous value */
        DisposeRgn( saveClipRgn );      /* not needed any more */

Note that there is no error checking on either the call to "NewRgn" or
the call to "GetClip".  It struck me that if I wanted to be completely
safe, I should check for errors after each of those calls.

I pulled out the NIM volume "Imaging with Quickdraw" to check what the
most modern advice from Apple is on these calls.  The description of
"NewRgn" doesn't mention that the call might fail and what would happen
in that case.  For example, it doesn't explicitly state that NewRgn
would return NULL if the allocation failed, though I assume it would.

In the description of "GetClip", they don't say what happens if the call
fails.  They do mention that you could check if the call might succeed
before you make it by calling MaxMem.

I remember reading that the Toolbox itself would crash if there wasn't a
small amount of memory (like 2K) available in the heap so that calls
like this are guaranteed to succeed.  Is that the prevailing opinion
regarding calls such as this.  Should we simply assume that they always
succeed because allocating a 10 byte handle and copying what is usually
a small tens of bytes or less clipRgn are will within this minimum
memory cushion?

Would you recommend writing code like this (using TCL-style exceptions):

        Size growBytes;

        saveClipRgn = NewRgn();         /* get an empty region */

        FailNIL(saveClipRgn);

        if (qd.thePort->clipRgn.rgnSize < MaxMem(&growBytes)) {

                GetClip( saveClipRgn ); /* save current */

                SetClip( myClipRgn );   /* install desired clipRgn */

                /*... ( draw a figure )  ... */

                SetClip( saveClipRgn ); /* restore previous value */
                DisposeRgn( saveClipRgn ); /* not needed any more */

        }

Would that be completely safe?  Would it be reasonable or overkill?
The call to MaxMem seems particularly silly.

What's the latest thinking?  Should we assume NewRgn and GetClip
never fail?  Is this why we should always have a GrowZoneProc that
can alway come up with a little more memory for such cases?

Thanks,

--Steve

--
Stephen C. Gilardi
SQ Software
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Grobbins)
Date: Thu, 08 Jun 1995 10:42:14 -0700
Organization: Skunkworks

In article <3r4t25$[e-mail]>, [e-mail] (Squeegee) wrote:
>[ Note:  In composing my message, I answered my own question.  I figured
>  I'd post it anyway so I can be corrected if I'm wrong, and because
>  maybe someone will benefit from reading it.  The answer is that it's
>  probably best not to error check these functions (there's really no
>  great way to do it anyway) and have a GrowZoneProc which manages a
>  small amount of reserve memory to guarantee that these functions don't
>  fail due to lack of memory.

It's true that most apps won't bother error-checking tiny allocations such
as a new region allocation.  The primary advantage of checking the success
of those calls would be to find out if the system is already hosed.  For
example, if h = NewHandle(10) were to fail, odds are not that memory is
tight, but rather that something is corrupted in the heap.  For this
reason, asserting during development that a tiny allocation succeeded is
useful [for example,   #if DEBUG     if (h == nil) DebugStr("\p newhandle
failed, something is really wrong");     #endif ]

GrowZone procs are really rather archaic, though.  They were appropriate
for a day when heaps were not automatically grown at launch with
MaxApplZone, in order to avoid limiting stack space, and when apps really
did have to worry about running down to their last few bytes.  But there
is little a growZone proc can do safely, since it is called from within
Memory Manager operations and thus is subject to toolbox reentrancy
problems.

A reasonable strategy these days is to simply make certain that an app has
a maximized heap and an adequate buffer of free space available.  For
medium-to-large applications, checking that there is always something like
30K or even twice that available is not unreasonable.  When memory becomes
tight, then, the app detects it long before the toolbox is likely to have
a problem, and the app can take whatever steps it deems appropriate --
freeing up reserve blocks, writing data to disk, or warning the user and
disabling features, for example.  Your level of paranoia may drive you to
install a growZone proc as well, but something is wrong if that's the
first place a low-memory situation is detected.

Grobbins                           [e-mail]

---------------------------

>From [e-mail] (Daniel B. Bogan)
Subject: GWorlds-CopyBits
Date: 15 Jun 1995 19:40:45 GMT
Organization: Khazad-dum BBS

I'm having great difficulty in getting GWorlds and CopyBits to work in THINK C
6.0.
I'm in desperate need of assistance! <stress>

Basically, I can't get either to work how i'd like them to I want to be able
to do animation with CopyBits, etc. etc. So far, no luck.

Does anyone have any text files/code/suggestions?

Much appreciated.

(I'm not *sure*, but is it possible that in my version is fairly different to
5?
 Because i've looked at code from 5.0, and it let's you SetPort to a GWorld,
but mine doesn't...<ponder>)

Thanks,
    DB

+++++++++++++++++++++++++++

>From [e-mail] (Scott L. Foglesong)
Date: 16 Jun 1995 08:04:15 GMT
Organization: CRIS

In article <[e-mail]>,
[e-mail] says...
>
>I'm having great difficulty in getting GWorlds and CopyBits to
work in THINK C
>6.0.
>I'm in desperate need of assistance! <stress>
>
>Basically, I can't get either to work how i'd like them to I
want to be able
>to do animation with CopyBits, etc. etc. So far, no luck.
>
>Does anyone have any text files/code/suggestions?
>
>Much appreciated.
>
>(I'm not *sure*, but is it possible that in my version is
fairly different to
>5?
> Because i've looked at code from 5.0, and it let's you SetPort
to a GWorld,
>but mine doesn't...<ponder>)

One of the big changes in post-5.0 versions of THINK C is that
they are considerably fussier about type checking. Although you
can turn some of that off in the compiler options settings, it's
really a pretty good idea to keep them fussy since it helps you
to avoid sometimes minor but hard-to-find bugs.

I'm not sure if this is your problem or not, but just try adding
a cast for the type you want with SetPort() and see if that
works. SetPort is normally defined is taking a GrafPtr--so that
may be all you need.

When I moved from THINK C 5 to 7, I spent quite a bit of time
going back over things that worked previously and having to
work out more casts. Kind of annoying but I suppose in the long
run it's all for the best.

--
- ---------------------------
Scott L. Foglesong
San Francisco Conservatory of Music
[e-mail] // [e-mail]
"Too many notes, my dear fellow, too many notes."
- ---------------------------


+++++++++++++++++++++++++++

>From Steve Sauder <[e-mail]>
Date: 16 Jun 1995 13:18:04 GMT
Organization: North Plains Systems Inc.

[e-mail] (Scott L. Foglesong) wrote:
>> Because i've looked at code from 5.0, and it let's you SetPort
>to a GWorld,
>>but mine doesn't...<ponder>)

[snip]

>I'm not sure if this is your problem or not, but just try adding
>a cast for the type you want with SetPort() and see if that
>works. SetPort is normally defined is taking a GrafPtr--so that
>may be all you need.

SetPort is not safe to use with GWorlds.  You should be using
SetGWorld(...) instead.  So, instead of doing this:

GrafPtr svPort;
GetPort(&svPort);
SetPort((GrafPtr) myGWorld);
..
SetPort(svPort);

You should do this:

CGrafPtr svPort;
GDHandle svDev;
GetGWorld(&svPort, &svDev);
SetGWorld(myGWorld, nil);
..
SetGWorld(svPort, svDev);

This is because off-screen GWorlds may (and probably will) reside
in a different *device*, and SetPort will not take this into
account, causing possible system crashes and various other mean
stuff when you attempt to work in your GWorld.

Regards,
Steve.

- ------------------------------------------------------------------
Steve Sauder                                     [e-mail]
North Plains Systems Inc.
Macintosh Software for Electronic Publishing



+++++++++++++++++++++++++++

>From [e-mail] (Alex Metcalf)
Date: Fri, 16 Jun 1995 16:38:07 GMT
Organization: The Twilight Zone

Daniel B. Bogan ([e-mail]) wrote:
: I'm having great difficulty in getting GWorlds and CopyBits to work in
: THINK C 6.0. I'm in desperate need of assistance! <stress>

: Basically, I can't get either to work how i'd like them to I want to be
: able to do animation with CopyBits, etc. etc. So far, no luck.

: Does anyone have any text files/code/suggestions?

        First you need to get hold of the right documentation on GWorlds.
The best place (if you're low on cash) is good ol' Inside Mac 6. I'm sure
there's a new Inside Mac book which covers offscreen worlds, but I haven't
got the money to find out. :)

        Next, remember a couple of golden rules. One such rule is you must
use LockPixels on a GWorld before doing anything with it. Another problem
which catches people out is the CopyBits command: people often dereference
or reference a variable too many times, and things go nuts. For GWorld to
screen:

CopyBits ((BitMap *) *worldPixMap, (BitMap *) &screenWindow->portPixMap,
   sourceRect, destRect, srcCopy, nil);

        I'm doing that from memory, but I think that's about right. A
quick fudge to remember: use * for your GWorld and & for your screen window.

<snip>

: (I'm not *sure*, but is it possible that in my version is
: fairly different to  5?
: Because i've looked at code from 5.0, and it let's you SetPort to a GWorld,
: but mine doesn't...<ponder>)

        You need to use GetGWorld and SetGWorld:

CGrafPtr  savedPort;
GDHandle  savedDevice;

GetGWorld (&savedPort, &savedDevice);
SetGWorld (myWorld, nil);
...
// do drawing to world here
...
SetGWorld (savedPort, savedDevice);

        At least, I _think_ they're called GetGWorld and SetGWorld. :)

        One final thing: if you're writing a game and you don't care much
about memory, use LockPixels on your GWorld Pix Maps immediately after you
create the GWorlds, and then leave it locked throughout the game. You need
never use LockPixels again...




        Alex :)

--
Alex Metcalf             Windows 95: Just another
[e-mail]        pane in the glass.

http://www.fen.bris.ac.uk/students/am4001/


---------------------------

>From [e-mail] (Sam Huffman)
Subject: Getting the selected portion of an editText item
Date: 1 Jun 1995 15:41:43 GMT
Organization: University of Michigan

I hope someone can help me with this:

I have a dialog box with several editText items. After the user selects a
portion of the text in one particular editText item, I would like to
retrieve the _selected_ portion into a string. For example, if the
editText field contained "The Quick Brown Fox" and the user selected
"Quick Bro" then as soon as he releases the mouse button I want to
retrieve "Quick Bro" into a string.

I assume I will need to write an event filter to filter out mouseUp
events. However, after I have done this how can I determine which item the
user has clicked in? Furthermore, how can I determine what the selected
portion is?

I appreciate any help anyone can give me.

Sam Huffman
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (F. Degott)
Date: 15 Jun 1995 11:48:33 GMT
Organization: LMC-IMAG Grenoble France

In article <schmeul-0106951139570001@162.48.124.18>, [e-mail]
(Sam Huffman) wrote:

>I hope someone can help me with this:
>
>I have a dialog box with several editText items. After the user selects a
>portion of the text in one particular editText item, I would like to
>retrieve the _selected_ portion into a string. For example, if the
>editText field contained "The Quick Brown Fox" and the user selected
>"Quick Bro" then as soon as he releases the mouse button I want to
>retrieve "Quick Bro" into a string.
>
>I assume I will need to write an event filter to filter out mouseUp
>events. However, after I have done this how can I determine which item the
>user has clicked in? Furthermore, how can I determine what the selected
>portion is?
>
>I appreciate any help anyone can give me.
>

Hi Sam,

if you use a ModalDialog call,
it's not necessary to write a event filter for that job.
When the user works on an item of your dialog, ModalDialog
returns the item id in the itemHit var.
In this case, you can detect clicks on edit text, and get the
TEHandle (corresponding to the edit text) in the textH field
of the DialogPeek record. So, you can access the selection
range of the active edit text with the selStart and selEnd
fields in textH^^.


repeat
      ModalDialog(nil,itemHit);
      if itemHit=MyEditTextID then
      begin
            SelectionStart:=DialogPeek(MyDlog)^.textH^^.selStart;
            SelectionEnd:=DialogPeek(MyDlog)^.textH^^.selEnd;
      end;
until itemHit in [ok,cancel];


For more info, see the dialog manager (IM vol 1)

Hope this helps.
Fr
_____________________________________________________
F.R. Degott  ([e-mail])
LogiMath at Lab. LMC-IMAG - Univ. Joseph Fourier - Grenoble - France
 "Quand on n'a pas ce qu'on aime, on aime ce qu'on a."

+++++++++++++++++++++++++++

>From [e-mail] (Christopher Larson)
Date: 15 Jun 1995 16:35:29 GMT
Organization: UCLA, Computer Science Department

In article <schmeul-0106951139570001@162.48.124.18> [e-mail] (Sam Huffman) writes:
>I have a dialog box with several editText items. After the user selects a
>portion of the text in one particular editText item, I would like to
>retrieve the _selected_ portion into a string. For example, if the
>editText field contained "The Quick Brown Fox" and the user selected
>"Quick Bro" then as soon as he releases the mouse button I want to
>retrieve "Quick Bro" into a string.
>
>I assume I will need to write an event filter to filter out mouseUp
>events. However, after I have done this how can I determine which item the
>user has clicked in? Furthermore, how can I determine what the selected
>portion is?

You don't need to write an event filter to do this. Make sure that in your
DITL, the editText items are enabled (meaning ModalDialog() will return when
the user interacts with them). Call ModalDilaog() in a loop and check the
itemHit parameter for one of the editText item numbers.

When ModalDialog() indicates that an editText item was touched, grab the
TEHandle stored in the dialog record and examine the selStart and selEnd
fields (I may have those names wrong, look in IM: Text). If these fields
contain the same value, there is no selection (it's an insertion point).
If they contain differing values, there is a selection and the values are
indices into the raw text of the text edit record. Simply grab the text
between these indices (including the lower index and excluding the upper
index, I _think_; check this in IM: Text as well).

--Chris
_______________________________________________________________________________
Chris Larson -- Amateur Macintosh Geek, CoBase Research Assistant
L.A. Institute of Slowly and Painfully Working Out the Surprisingly Obvious
- -------------------------------------+---------------------------------------
(Insert Disclaimer Here)               | Who's the man ridin' in the sun?
UCLA Bruins--1995 NCAA Men's Basketball| Who's the man with the itchy gun?
             National Champions (yea!) | Who's the man who kills for fun?
Internet: [e-mail]  | Psycho Dad, Psycho Dad, PSYCHO DAD!

+++++++++++++++++++++++++++

>From [e-mail] (David Newman)
Date: Thu, 15 Jun 1995 11:56:22 -0500
Organization: University of Texas Department of Philosophy

Sam,

Again, assuming that I understand your problem, you don't need to filter
out mouse events, but key events to prevent the user from editing the text
that you want them to select from.  In addition, after the user has
dismissed the dialog, and before you dispose it, you can get the TEHandle
from the dialog, and use the following procedure to get the selection from
it as a string.

I assume that there is only one editable text item in the dialog. Also,
the procedure setStringLength sets the length byte of a string to be what
I want it to be, regardless
of the contents of the string.

 procedure getTESelection (theTERec: TEHandle;
       var theString: str255);

{ A procedure to get the selected text of a TE record as a str255. }

  var
   tempString: str255;
   theStart, theEnd, theLength: integer;
   theText: charsHandle;

 begin
  tempString := '';
  theText := TEGetText(theTERec);
  theStart := theTERec^^.selStart;
  theEnd := theTERec^^.selEnd - 1;
  theLength := theEnd - theStart + 1;
  if theLength > 0 then begin
    hLock(handle(theText));
    if theLength <= 255 then begin
      setStringLength(tempString, theLength);
      blockMove(@theText^^[theStart], @tempString[1], theLength);
     end;
    hUnlock(handle(theText));
   end;
  theString := tempString;
 end; { getTESelection }

---------------------------

>From [e-mail] (Jens Alfke)
Subject: Licensing the PEF format: the answer
Date: Tue, 6 Jun 1995 17:02:39 GMT
Organization: Apple Computer, Inc.
There were some questions a while back about the PEF format (the format
for executable code on PowerMacs and CFM68K) and how to get the details
from Apple. As promised, I asked people around here and got the following
official response:

"The PEF file format is patented. We widely license the format. For a
commercial product, the license fee is $250.00 forever. For non-commercial
products, the license fee is $0.00 forever. [I.e. free.]
Anyone that is interested in licensing should contact
[e-mail]."

Sounds pretty reasonable to me.


Jens Alfke_________OpenDoc [e-mail]
                                           OpenDoc info: FTP to CILabs.org

                LLAMA: NO FEAR OF SPIKES

+++++++++++++++++++++++++++

>From [e-mail] (Bo Lindbergh)
Date: 8 Jun 1995 20:55:20 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

In article <[e-mail]> [e-mail] (Jens Alfke) writes:
)
) "The PEF file format is patented. We widely license the format. For a
) commercial product, the license fee is $250.00 forever. For non-commercial
) products, the license fee is $0.00 forever. [I.e. free.]
) Anyone that is interested in licensing should contact
) [e-mail]."

Hmm.  What's the patent number?  And where is the revolutionary new idea
that allowed it to be patented? :-)


/Bo Lindbergh

+++++++++++++++++++++++++++

>From [e-mail] (John McEnerney)
Date: Fri, 9 Jun 1995 00:41:03 GMT
Organization: Metrowerks, Inc.

In article <3r7o3o$[e-mail]>, [e-mail] (Bo
Lindbergh) wrote:

> ) "The PEF file format is patented. We widely license the format. For a
> ) commercial product, the license fee is $250.00 forever. For non-commercial
> ) products, the license fee is $0.00 forever. [I.e. free.]
> ) Anyone that is interested in licensing should contact
> ) [e-mail]."
>
> Hmm.  What's the patent number?  And where is the revolutionary new idea
> that allowed it to be patented? :-)

There are apparently several issues that were patentable. One was possibly
the scheme used to determine whether a client and library versions are
compatible. Another was almost certainly the design for representing
relocation information; consider that PEF can represent relocations for a
very large programs in only a few hundred bytes. Other commercial
executable file formats (e.g. XCOFF) require orders of magnitude more
space to represent the needed runtime relocations.

PEF is a nice piece of work!

--
John McEnerney ([e-mail])
Metrowerks PowerPC Compiler Architect

+++++++++++++++++++++++++++

>From [e-mail] ([e-mail])
Date: 9 Jun 1995 15:23:01 GMT
Organization: Dartmouth College, Hanover, NH

In article <johnmce-0806952041420001@192.0.2.1>
[e-mail] (John McEnerney) writes:
> In article <3r7o3o$[e-mail]>, [e-mail] (Bo
> Lindbergh) wrote:
>
> > ) "The PEF file format is patented. We widely license the format. For a
> > ) commercial product, the license fee is $250.00 forever. For non-commercial
> > ) products, the license fee is $0.00 forever. [I.e. free.]
> > ) Anyone that is interested in licensing should contact
> > ) [e-mail]."
> >
> > Hmm.  What's the patent number?  And where is the revolutionary new idea
> > that allowed it to be patented? :-)
>
> There are apparently several issues that were patentable. One was possibly
> the scheme used to determine whether a client and library versions are
> compatible. Another was almost certainly the design for representing
> relocation information; consider that PEF can represent relocations for a
> very large programs in only a few hundred bytes. Other commercial
> executable file formats (e.g. XCOFF) require orders of magnitude more
> space to represent the needed runtime relocations.

It is my understanding that the packing algorithm (which is an RLE
scheme) is also one of the patented parts.  This is understandable
(that it would be patentable in the eyes of PTO, that is) because most
of the compression engines available today are patented.

> PEF is a nice piece of work!

Yes, that is an understatement.  Compare it to most other executable
file formats, especially Windows and COFF (Windows NT/95), and you will
see why Apple deserves credit.

Mark.

---------------------------

>From [e-mail] (Russell N. Sheptak)
Subject: MacTCP and Native code
Date: Thu, 08 Jun 1995 18:20:17 -0700
Organization: Desktop Data, Inc.

In moving my application native, I ran into some real performance
problems with native code and MacTCP.  I assume its the context
switches in the completion routines that are killing me.  Is this
another case of code better left in the 68K world?  If not, what's
the best (performance) way to deal with the problem?  Loadable
68K stand-alone code resource?  Suggestions welcome.

rus

+++++++++++++++++++++++++++

>From [e-mail] (Eric Scouten)
Date: Fri, 09 Jun 1995 02:54:50 -0500
Organization: Metrowerks, Inc.

In article <[e-mail]>, [e-mail]
(Russell N. Sheptak) wrote:

> In moving my application native, I ran into some real performance
> problems with native code and MacTCP.  I assume its the context
> switches in the completion routines that are killing me.  Is this
> another case of code better left in the 68K world?  If not, what's
> the best (performance) way to deal with the problem?  Loadable
> 68K stand-alone code resource?  Suggestions welcome.

If you're writing code that calls MacTCP asynchronously, you should at
least make your completion routines in 68K. This will boost your
performance, since MacTCP is in 68K mode already.

If your completion routine needs only minimal access to your data
structures (and no access to global variables), you can accomplish this
fairly easily with a standalone code resource. (See my TurboTCP library as
an example.) It's probably not necessary from a performance standpoint to
write the rest of your program in 68K; I/O bandwidth will be the primary
bottleneck anyway.

FYI, under optimal conditions (unbusy Ethernet, unbusy server, no other
apps running, etc.) MacTCP will max out at about ~410KB/sec (receive).
Anything beyond this is probably out of reach, no matter how well you've
written your code (at least until Open Transport comes along).

-es

__________________________________________________________________________
Eric Scouten                                       Constructor Constructor
[e-mail]                                     Metrowerks, Inc.

The Pledge of Allegiance says, "liberty and justice for all."
Which part of "all" don't you understand?
   -Rep. Pat Schroeder

+++++++++++++++++++++++++++

>From [e-mail] (Peter N Lewis)
Date: Thu, 15 Jun 1995 13:31:23 +0800
Organization: Curtin University

In article <[e-mail]>, [e-mail]
(Russell N. Sheptak) wrote:

>In moving my application native, I ran into some real performance
>problems with native code and MacTCP.  I assume its the context
>switches in the completion routines that are killing me.  Is this
>another case of code better left in the 68K world?  If not, what's
>the best (performance) way to deal with the problem?  Loadable
>68K stand-alone code resource?  Suggestions welcome.

I haven't bothered going native with my code for exactly this reason.
However, other apps (like NewsWatcher and Eudora) don't seem to suffer too
badly in performance.  Perhaps check out Fetch too, it's Native and
requires high performance networking, see how it compares to running
emulated Anarchie...?
   Peter.

+++++++++++++++++++++++++++

>From [e-mail] (Mike Alexander)
Date: Thu, 15 Jun 1995 21:35:50 -0400
Organization: University of Michigan

In article <[e-mail]>, [e-mail]
(Russell N. Sheptak) wrote:

> In moving my application native, I ran into some real performance
> problems with native code and MacTCP.  I assume its the context
> switches in the completion routines that are killing me.  Is this
> another case of code better left in the 68K world?  If not, what's
> the best (performance) way to deal with the problem?  Loadable
> 68K stand-alone code resource?  Suggestions welcome.

The best medium to long term solution is to use Open Transport, which is
potentially native right down to the wire depending on the particular
transport protocol being used.  Of course, this doesn't help much until
most people have Open Transport which won't happen for a while.  In the
meantime, it's probably not worth putting a lot of effort into solving
this problem with the old MacTCP.

Mike Alexander              Internet:       [e-mail]
University of Michigan      America Online: MAlexander
ITD - Research Systems      AppleLink:      UMICH

---------------------------

>From [e-mail]
Subject: MacTech vs. develop
Date: 14 Jun 95 12:53:31 CST
Organization: Johnson Space Center; Houston, Tx

Hello,

A quick question to all you experienced Mac Hackers...

Which would be a more useful subscription for a beginner-to-intermediate Mac
programmer, MacTech ($40/yr through AOL) or d e v e l o p ($30/yr APDA)?  I've
looked at single issues of both, and they both seem to have their merits.

One advantage of MacTech are 12 issues (vs. 4 for develop) a year.  Develop,
however, seems to have more substance per issue.  You also get the bookmark
CD's with develop with all the back issues, IM's, etc.   How important are the
bookmark CD's, really?  It seems that a lot of the material is redundant after
you have a few.  I bought develop #17 single issue, so I have most of the
"essential" (for my current level of competance, anyway) volumes of IM.

Anyway, my wife asked me what I wanted for Father's Day, and I need to give her
an answer soon or else I think I'll be getting another tie :)

All opinions are welcome.

Thanks,
russ
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Joey Gray)
Date: Thu, 15 Jun 1995 09:46:26 -0500
Organization: Northwestern University

In article <[e-mail]>,
[e-mail] wrote:

>Which would be a more useful subscription for a beginner-to-intermediate Mac
>programmer, MacTech ($40/yr through AOL) or d e v e l o p ($30/yr APDA)?  I've
>looked at single issues of both, and they both seem to have their merits.

that probably depends on just how experienced you are, and what you're
looking for. develop seems to concentrate on some of the newer and/or more
difficult issues of macintosh programming, while mactech seems to
concentrate on the more mundane, day-to-day types of things that macintosh
programmers face. not that they both don't have exceptions to this, it's
just my take on the relative uses of the magazines. i have had a
subscription to both for a couple of years now, and very much enjoy both
of them. hey, ask for both!

>One advantage of MacTech are 12 issues (vs. 4 for develop) a year.  Develop,
>however, seems to have more substance per issue.  You also get the bookmark
>CD's with develop with all the back issues, IM's, etc.   How important are the
>bookmark CD's, really?  It seems that a lot of the material is redundant after
>you have a few.  I bought develop #17 single issue, so I have most of the
>"essential" (for my current level of competance, anyway) volumes of IM.

yes, the cd's do become a bit redundant. unless some example code is
updated, or new example code is added, that portion of the cd seems to
remain pretty much the same. the good stuff on each cd is the code and
example programs (and what not) that are discussed in the magazine. i'm
not sure if that stuff is duplicated on each subsequent cd, but i doubt
it.

>Anyway, my wife asked me what I wanted for Father's Day, and I need to give her
>an answer soon or else I think I'll be getting another tie :)

a tie!?! just say "no" to the noose!

>All opinions are welcome.

you asked for it.

-joey
=====================================================================
Joey Gray                       | [e-mail]
School of Education             | [phone]
Northwestern University         +------------------------------------
**Bandwagon disclaimer:         | "Anybody can cook with gas --
   My opinions are mine, not my |  it takes the French to cook with
   employer's. so there!        |  magnets!" - old newsreel
=====================================================================

+++++++++++++++++++++++++++

>From [e-mail] (Steve Bryan)
Date: Thu, 15 Jun 1995 15:24:08 GMT
Organization: Sexton Software

In article <[e-mail]>,
[e-mail] wrote:

> Which would be a more useful subscription for a beginner-to-intermediate Mac
> programmer, MacTech ($40/yr through AOL) or d e v e l o p ($30/yr APDA)?  I've
> looked at single issues of both, and they both seem to have their merits.
...
> Anyway, my wife asked me what I wanted for Father's Day, and I need to
give her
> an answer soon or else I think I'll be getting another tie :)


Ask her for MacTech and order develop yourself. Seriously I would strongly
suggest getting both. It is not at all redundant like subscribing to
MacWorld and MacUser where you get the same ads twice.

--
|Steve Bryan                Internet: [e-mail]
|Sexton Software          CompuServe: 76545,527
|Minneapolis, MN 55415           Fax: [phone]
|PGP key fingerprint: B4 C6 E2 A6 5F 87 57 7D  E1 8C A6 9B A9 BE 96 CB

+++++++++++++++++++++++++++

>From [e-mail] (John Kawakami)
Date: Fri, 16 Jun 1995 03:11:09 GMT
Organization: Xplain Corp.

In article <[e-mail]>,
[e-mail] wrote:

> Hello,
>
> A quick question to all you experienced Mac Hackers...
>
> Which would be a more useful subscription for a beginner-to-intermediate Mac
> programmer, MacTech ($40/yr through AOL) or d e v e l o p ($30/yr APDA)?  I've
> looked at single issues of both, and they both seem to have their merits.
>
> One advantage of MacTech are 12 issues (vs. 4 for develop) a year.  Develop,
> however, seems to have more substance per issue.  You also get the bookmark
> CD's with develop with all the back issues, IM's, etc.   How important are the
> bookmark CD's, really?  It seems that a lot of the material is redundant after
> you have a few.  I bought develop #17 single issue, so I have most of the
> "essential" (for my current level of competance, anyway) volumes of IM.
>
> Anyway, my wife asked me what I wanted for Father's Day, and I need to
give her
> an answer soon or else I think I'll be getting another tie :)
>
> All opinions are welcome.
>
> Thanks,
> russ
> [e-mail]

I'd say get both, but send the check to MacTech first <g>

The MacTech staff reads develop, and the develop people say they read
MacTech.  Those develop editors and writers are pretty darn smart, and I
think you should follow their lead and read MacTech.  The magazines don't
overlap that much; MacTech covers third party products as well as Apple
technology and programming techniques, while develop is heavily oriented
toward Apple technology.  MacTech has advertisements, so you can keep up
on third party tools and products.  And perhaps most importantly, MacTech
is not operated by Apple, it's an independent magazine.

As for develop's redundant CDs: it's impossible to create 600 MB of new
content every three months (unless you do something like create archives
of comp.sys.mac.programmer.* postings.)  And speaking of CDs, MacTech has
a nifty little CD with all the old MacTech articles in Think Reference
hypertext.

If any of you out there didn't already know, you can get a "online user
discount" off the regular subscription price by filling out a form
available on ftp://ftp.netcom.com/pub/xp/xplain
John Kawakami, [e-mail]

- -MacTech Magazine--------------------------------------------------
PO Box 250055, Los Angeles, CA 90025, 310-575-4343, Fax:[phone]
For more info, ftp://ftp.netcom.com/pub/xp/xplain

+++++++++++++++++++++++++++

>From [e-mail] (Shawn Lavin)
Date: 16 Jun 1995 17:58:04 GMT
Organization: HoloNet National Internet Access System: 510-704-1058/modem

[e-mail] wrote:

> Which would be a more useful subscription for a beginner-to-intermediate Mac
> programmer, MacTech ($40/yr through AOL) or d e v e l o p ($30/yr APDA)?  I've
> looked at single issues of both, and they both seem to have their merits.

Add my vote to the 'both' catagory. They address different concerns and
both consistantly contain a wealth of good articles. Get her to order
MacTech for you and buy d e v e l o p yourself (that way she can see
her gift arriving 12 times). I have had subscriptions to both for years
and have never considered letting them lapse.

I consider these essential for the hobbyist Mac programmer, and not
a bad idea for the prefessional.

--
Shawn Lavin
([e-mail])

As always, my opinions are my own

---------------------------

>From [e-mail] (john hazen)
Subject: MacsBug Docs? (was Re: Where are the @$# keyUp events?!!)
Date: Thu, 8 Jun 1995 00:04:02 GMT
Organization: Netcom Online Communications Services (408-241-9760 login: guest)


I've been looking on and off for the docs on how to use MacsBug for 2
months now.  I've looked on various developer CDs and on the CodeWarrior
CD.  Can anyone out there point me in the right direction?

Thanks in advance.

John Hazen

+++++++++++++++++++++++++++

>From [e-mail] (Alain Roy)
Date: Thu, 8 Jun 1995 15:23:50 GMT
Organization: None

In article <[e-mail]>, [e-mail] (john hazen)
wrote:

>I've been looking on and off for the docs on how to use MacsBug for 2
>months now.  I've looked on various developer CDs and on the CodeWarrior
>CD.  Can anyone out there point me in the right direction?

I learned much of Macsbug from the builtin help. Type 'help' when in Macsbug.

The only manual I know of, you have to buy. Oh well, at least the debugger
is free. Also, the manual covers version 6.2.2--for the most part that's
ok. If you read the release notes with macsbug, you should be set.

I think that it's quite a good manual. Here's the Table of Contents:

1. Macsbug & Low-Level Debugger
2. Getting Started
3. An Assembly Language Primer
4. Macintosh Memory Organization
5. The Macintosh Operating System
6. Discipline
7. Debugging Strategies
8. Introduction to Macsbug Commands
9. Macsbug Commands.

It's called _MacsBug References and Debugging Guide_
Subtitled: "For MacBug version 6.2"
ISBN 0-201-56767-9
$24.95/USA
$31.95/Canada

Hope this helps.

I've been thinking of writing a MacsBug FAQ. Anyone want to donate their
favorite MacsBugs tips or tricks?

-alain

---------------------------

>From [e-mail] (Scott Taschler)
Subject: Overwhelmed newbie needs encouragement
Date: Tue, 6 Jun 1995 01:58:38 GMT
Organization: University of Minnesota

Hello everyone,

I've recently begun to try to pick up some Mac programming.  I've got a
few of the Inside Mac books, as well as Dave Mark's book, and have gone
through the examples.  This toolbox stuff is driving me buggy!  There is
so much to understand, I have become overwhelmed to the point that it
seems like a mammoth undertaking to even try a *small* mac project.  Even
printing an error message takes a major effort.  Required AppleEvents,
proper preference files, being background friendly...you see my point.

So, what advice can you veterans out there give to help me get up to
speed?  A few ideas that I have thought of are:

o  Finding a good library out there that provides the basic framework for
an application, so I can just fill in the unique details of my app

o  A good toolkit to isolate some of the complications of the toolbox?
(ala Tcl/Tk in the UNIX world.)

o  Perhaps a good class library is what I need.  TC++ has the Visual
Architect, which looks promising, but the Think Class Library is hardly
any more simple than the standard toolbox, is it?

Any pointers will be gratefully gulped down.  I can't be the only one out
here that has become frustrated with the daunting task of trying to master
the toolbox.

- -------------------------------------------------------------------
Scott "Scooter" Taschler  \  "We should tackle reality in a slightly
University of Minnesota   \   joky way, otherwise we miss its point"
[e-mail]  \   --Lawrence Durrel

+++++++++++++++++++++++++++

>From [e-mail] (Chris Ellens)
Date: Tue, 06 Jun 1995 08:57:21 -0400
Organization: BNR

In article <[e-mail]>,
[e-mail] (Scott Taschler) wrote:

] Hello everyone,
]
] I've recently begun to try to pick up some Mac programming.  I've got a
] few of the Inside Mac books, as well as Dave Mark's book, and have gone
] through the examples.  This toolbox stuff is driving me buggy!  There is
] so much to understand, I have become overwhelmed to the point that it
] seems like a mammoth undertaking to even try a *small* mac project.  Even
] printing an error message takes a major effort.  Required AppleEvents,
] proper preference files, being background friendly...you see my point.
]
] So, what advice can you veterans out there give to help me get up to
] speed?  A few ideas that I have thought of are:
]
] o  Finding a good library out there that provides the basic framework for
] an application, so I can just fill in the unique details of my app
]
] o  A good toolkit to isolate some of the complications of the toolbox?
] (ala Tcl/Tk in the UNIX world.)
]
] o  Perhaps a good class library is what I need.  TC++ has the Visual
] Architect, which looks promising, but the Think Class Library is hardly
] any more simple than the standard toolbox, is it?
]
] Any pointers will be gratefully gulped down.  I can't be the only one out
] here that has become frustrated with the daunting task of trying to master
] the toolbox.


You're right, you're not the only one. However everything suddenly seems
less daunting when you start to realize how much that toolbox (and a good
framework like the TCL) does for you that you don't have to code/debug
yourself.

If you're comfortable with C (with C++ even better) then I recommend the
Think Class Library. It serves a different purpose than the toolbox -
think of it as an application "shell" - a generic application that you
just tweak to get what you want. However be prepared for lots more
frustration when you first dive into it, especially if you're new to
object-oriented programming. You have to twist your brain for a while
before you start to see things the oop (and TCL) way.

I've been struggling to teach myself C, C++, OOP, TCL, and the Mac toolbox
in my (limited) spare time for about a year now, and I'm an experienced
programmer (PL/I, Fortran, and Pascal). A few months ago it was like
waking up - when this whole TCL thing started to make sense. Now I'm
amazed at how obvious it is what I have to do to add a new feature to my
code.

There's also Visual Architect, which allows you to design an interface on
your screen and get it running almost instantaneously. Then you can go
poke around the generated (TCL) code and try to figure out how it works.

If you're not tied to C and C++ and you have a bit of cash to blow, you
could also check out Prograph, which is a whole new way to program.
There's a demo CD available (I think - I haven't received mine yet) -
maybe somebody else here can comment on that.

--
Chris Ellens       [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (David Stone)
Date: Tue, 6 Jun 1995 13:13:28 GMT
Organization: University of Toronto Chemistry

In article <[e-mail]>,
[e-mail] (Scott Taschler) wrote:
>
> Hello everyone,
>
> I've recently begun to try to pick up some Mac programming.  I've got a
> few of the Inside Mac books, as well as Dave Mark's book, and have gone
> through the examples.  This toolbox stuff is driving me buggy!  There is
> so much to understand, I have become overwhelmed to the point that it
> seems like a mammoth undertaking to even try a *small* mac project.  Even
> printing an error message takes a major effort.  Required AppleEvents,
> proper preference files, being background friendly...you see my point.
>
> So, what advice can you veterans out there give to help me get up to
> speed?  A few ideas that I have thought of are:
>
<SNIP>


One thing I found helpful at first was using Prototyper when I first
started Mac programming.  This allowed be to design the user interface
and generated all the code I needed for the basic application framework
(including dialogs, alerts, windows, menus, controls...).  I have to
confess that I don't use it any more, but a tool like that is great
when you're just starting out.

I found the Think Class Library too overwhelming, even though I'd been
on the Mac about 3 years by the time I started using it.  I still use
the object extensions in SC 6, though (haven't graduated to C++ yet).

Don't get too hung up on making your first application(s) perfect -
you can go back and redo them later if you want to.  My first attempts
were all multifinder-ignorant and still ignore AppleEvents, but they
work fine and I keep fixing things as we go along (I will get around
to AE's one day...)

When I'm in a real hurry, I still (gasp!) use the SC 6 console window
with printf/scanf and no menus....you do what you have to do.

Keep at it, though - it really is worth the effort and it's a great
reward when people say how impressed they are with this professional-
-looking software you wrote!

Dave Stone

+++++++++++++++++++++++++++

>From [e-mail] (Francois Pottier)
Date: 6 Jun 1995 16:42:18 GMT
Organization: Ecole Normale Superieure, Paris

In article <[e-mail]>,
Scott Taschler <[e-mail]> wrote:

>o  Perhaps a good class library is what I need.

A good class library is definitely useful, but you will have a hard time
understanding how to use it at first, especially if you don't master the
Toolbox. I'm learning PowerPlant and it takes quite a bit of single-stepping
to get a general picture.

I would recommend getting a small framework such as TransSkel, which handles
the event handling mechanism for you, and understanding it well. Then you
can move on.

Good luck!


--
Francois Pottier                                            [e-mail]
- ----------------------------------------------------------------------------
Check my WWW page at http://acacia.ens.fr:8080/home/pottier/ ...

+++++++++++++++++++++++++++

>From [e-mail] (Ron Davis)
Date: Tue, 06 Jun 1995 12:34:39 -0400
Organization: Datawatch Corp

In article <[e-mail]>,
[e-mail] (Scott Taschler) wrote:

>through the examples.  This toolbox stuff is driving me buggy!  There is
>so much to understand, I have become overwhelmed to the point that it
>seems like a mammoth undertaking to even try a *small* mac project.  Even
>printing an error message takes a major effort.  Required AppleEvents,

I can remember feeling this way too.  You have to make a paradigm shift to
get into the GUI/event loop kind of thinking.  Start small and work your
way up.

>proper preference files, being background friendly...you see my point.
>
>So, what advice can you veterans out there give to help me get up to
>speed?  A few ideas that I have thought of are:

Here's some basic advice.  Start building a simple C shell.  You can
search around on the Net and find a few already there, but I'd suggest you
build your own rather than use someone elses.  Build a little at a time
like this.


   You have to make these calls but I don't think I've every written one from
   scratch.


   This would call GetNewMBar and handle adding the Apple menu.

   Call GetNewWindow and put up your window.

   Call WaitNextEvent and have a switch statement for all of the events.

   Branch off your event loop.  You should probably handle menu events first
   or you'll never be able to quit.

   you learn something new.

Hope that helps.

__________________________________________________________________
"I want to know God's thoughts...the rest are details."
                                           -- Albert Einstein
_________________________________________
Ron Davis           Software Engineer       [e-mail]
                    Finger [e-mail] for PGP key.
               http://www.cybernetics.net/users/rdavis/home.html
Opinions are MINE - Datawatch doesn't pay me enough to own my opinions.

+++++++++++++++++++++++++++

>From [e-mail] (Denis Lacasse)
Date: Wed, 7 Jun 1995 12:34:02 GMT
Organization: Centre de Recherche Informatique de Montrial

[e-mail] (David Stone) wrote:

[snip]

>One thing I found helpful at first was using Prototyper when I first

[snip]

Can you give more info on Prototyper? like is it still availble? How
much ?  What does it do?

Thanks!


+++++++++++++++++++++++++++

>From [e-mail] (FFllanagan)
Date: 7 Jun 1995 12:58:27 -0400
Organization: America Online, Inc. (1-800-827-6364)


>through the examples.  This toolbox stuff is driving me buggy!  There is
>so much to understand, I have become overwhelmed to the point that it
>seems like a mammoth undertaking to even try a *small* mac project.  Even
>printing an error message takes a major effort.  Required AppleEvents,
>proper preference files, being background friendly...you see my point.

I can remember that *very* well. What saved me was a wonderful skeleton
called TransSkel (by Paul DuBois et al). It makes the ToolBox much more
managable, and best of all, it's free. You can find it in all the usual
places, and it's compatible with THINK C, THINK Pascal, and Codewarrior.
It's definitely worth looking into.

Even with TransSkel, though, learning the ToolBox is *hard*. I've been
working with it for about a year and a half, maybe two years, and it's
still difficult for me. Be patient! :)

- Reid Priedhorsky
  (Author of Guy Smiley vs. the Monsters)

+++++++++++++++++++++++++++

>From [e-mail] (Clayburn Juniel/Effective Software Solutions)
Date: 8 Jun 1995 15:39:12 GMT
Organization: Primenet Services for the Internet [phone]

:   Branch off your event loop.  You should probably handle menu events first
:   or you'll never be able to quit.

By the way how do you get out of such a situation without rebooting?

I too am a newbie Mac programmer.  I started using Powerplant, but it
looks like it adds so much stuff to your code.  And its like a toolbox on
top of a tool box.  It does let you do some things without worrying about
writing code, but I think in the long run it would be better to write
that code yourself then you know exactly whats in it (until a few months
pass by and you completely forget :) ).-- Clay

WARNING! Opinions may change due to new information.
|--------------------------------------------------------------------|
|Effective Software Solutions   Clayburn W. Juniel, III              |
|Custom Software Design         1928 E. Camelback Rd. #623           |
|Phone:     [phone]       Phoenix, AZ   85016-4143   USA       |
|Fax:       [phone]                                            |
|Internet:  [e-mail]  WWW:  http://www.primenet.com/~clay1 |
|           [e-mail]  FTP:  ftp.primenet.com  users/c/clay1|
|--------------------------------------------------------------------|


+++++++++++++++++++++++++++

>From [e-mail] (Francois Pottier)
Date: 9 Jun 1995 09:17:02 GMT
Organization: Ecole Normale Superieure, Paris

In article <3r75j0$[e-mail]>,
Clayburn Juniel/Effective Software Solutions <[e-mail]> wrote:

>I too am a newbie Mac programmer.  I started using Powerplant, but it
>looks like it adds so much stuff to your code.  And its like a toolbox on
>top of a tool box.

You're right. PowerPlant is a medium-sized framework. In my opinion,
it is not suitable for complete beginners; a beginner should first
try a smaller framework such as TransSkel or try to write his own.
This will let him understand how the Mac works. PowerPlant, TCL,
MacApp and others are quite large and are useful if you want to
write a big, full-fledged application which you want to distribute
and maintain over time. Different goals.

For instance, I am making my application scriptable using PowerPlant
and it is a breeze (well, not really, but considering how hairy the
AEOM is...). PowerPlant is suited for large projects, not for
beginners.

Just my two cents, of course.




--
Francois Pottier                                            [e-mail]
- ----------------------------------------------------------------------------
Check my WWW page at http://acacia.ens.fr:8080/home/pottier/ ...

+++++++++++++++++++++++++++

>From [e-mail] (Shawn Lavin)
Date: 9 Jun 1995 16:25:09 GMT
Organization: HoloNet National Internet Access System: 510-704-1058/modem

Clayburn Juniel/Effective Software Solutions ([e-mail]) wrote:

: I too am a newbie Mac programmer.  I started using Powerplant, but it
: looks like it adds so much stuff to your code.  And its like a toolbox on
: top of a tool box.  It does let you do some things without worrying about
: writing code, but I think in the long run it would be better to write
: that code yourself then you know exactly whats in it (until a few months
: pass by and you completely forget :) ).-- Clay

The intended advantage to the frameworks are that they are already
written code for you to base your large projects off. They are supposed
to be well thought out, properly debugged and highly reliable. The
payoff for you is that after a lot less time studying them than you
would have spent writing and debugging them, you can start concentrating
on the unique bits that make your progrem unique.

That's the up side.

The down side, well since they are often everything and the kitchen sink
they tend to have a much larger disk/memory footprint than a custom written
program which only has the things that you want. In addition, if the
framework designer was designing a document centered application and
you are doing a database (or game), the fit of the framework to your
model may be poor, resulting in lots of work arounds. Also, not all
frameworks out there are well thought out, properly debugged or reliable.

What does this mean from a practical point of view ?

For most people, if they are writing a simple, well defined application,
the frameworks are overkill. When you choose a framework for a project, you
should choose one that is suitable for your type of project. Remember
when you are studying a framework to use it that you alternative is to
actually write those hundreds of classes (and debug and fix them).

--
Shawn Lavin
([e-mail])

As always, my opinions are my own

+++++++++++++++++++++++++++

>From [e-mail] (Ernie Soffronoff)
Date: 13 Jun 1995 16:04:50 GMT
Organization: StarNet Communications, Inc

I really like AppMaker.  It lets you draw the interface using grapic
tools and then generates enough code to get all the interface working.
You can then just plug your functional stuff in behind the menus and
buttons and such.  It's possible to get a working Mac application in just
a few hours.

That's how I did my first Mac application.  Now I end up changing more of
the stuff generated by AppMaker and might stop using it completely, but I
never would have gotten started if I hadn't used it.

There's a demo on the CW CD (at least there was in CW5, I haven't looked
for it on CW6 yet).  And I think it's going to do PowerPlant too, which
would be a good way to learn how to make a PowerPlant app.  (All I've
done has been THINK Pascal and CW procedural C.)

--Ernie
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Dale M Greer)
Date: 14 Jun 1995 05:36:58 GMT
Organization: The University of Texas at Dallas

Here's another vote for TransSkel.  It works well to get started, and
you've got all the source code to teach you how to roll your own, or
you can just go in and alter it to suit your own purposes.  The complete
package includes TransDisplay and TransEdit, which make it very easy to
get text display and editing.  The package also comes with many examples,
with projects in three flavors: MPW, THINK, and Metrowerks.

It is also very small for a framework.  The "Hello" sample is about
20K bytes.  I guess it isn't really a framework, but a skeleton.  Anyway,
it's small enough that you can look through the code and learn a lot
form it quickly, unlike most frameworks.

How come nobody's mentioned Sprocket?  I'll admit I've never used it, but
I just haven't gotten around to trying it out.

Finally, look into Apple's WWW and FTP sites for their code Snippets.
They've got a whole mess of examples for all of the older Mac software
managers.  Some of this code is getting a bit long in the tooth, but
that's usually okay if you're just beginning.  The only addresses I
remember off the top of my head are www.info.apple.com and ftp.apple.com.

--

Dale Greer, [e-mail]
"They know that it is human nature to take up causes whereby a man may
 oppress his neighbor, no matter how unjustly. ... Hence they have had
 no trouble in finding men who would preach the damnability and heresy
 of the new doctrine from the very pulpit..." - Galileo Galilei, 1615


+++++++++++++++++++++++++++

>From [e-mail] (Paul DuBois)
Date: 15 Jun 1995 09:48:55 -0500
Organization: Castra Parvulorum

>From article <3rlshq$[e-mail]>, by [e-mail] (Dale M Greer):
> Here's another vote for TransSkel.  It works well to get started, and
> you've got all the source code to teach you how to roll your own, or
> you can just go in and alter it to suit your own purposes.  The complete
> package includes TransDisplay and TransEdit, which make it very easy to
> get text display and editing.  The package also comes with many examples,
> with projects in three flavors: MPW, THINK, and Metrowerks.

Which version of TransSkel is this?  Bob's?  The standard version
(currently at release 3.20) is usable from THINK C (68K), Symantec
C++ (PPC), Metrowerks C (68K or PPC) and THINK Pascal -- i.e., no
MPW projects.  Release 3.21 will drop THINK Pascal support in favor
of Metrowerks Pascal (68K or PPC) support.

> It is also very small for a framework.  The "Hello" sample is
about > 20K bytes.  I guess it isn't really a framework, but a
skeleton.  Anyway, > it's small enough that you can look through
the code and learn a lot > form it quickly, unlike most frameworks.

That's good to hear, since that's one of its design goals.

> Finally, look into Apple's WWW and FTP sites for their code Snippets.
> They've got a whole mess of examples for all of the older Mac software
> managers.

I agree, and will add that in general, an essential part of learning
Macintosh programming is too look at other people's source code.  Reading
Inside Macintosh (or other documentation) is fine, but you also need to
see how people write code in real life.  Source code is particularly helpful
when you can find some that does something similar to what you want to do.
--
Paul DuBois
[e-mail]

"I'm going to learn worm-talk next," said Janetta  -- Grandaddy's Place

+++++++++++++++++++++++++++

>From [e-mail] (Clayburn Juniel/Effective Software Solutions)
Date: 15 Jun 1995 20:22:35 GMT
Organization: Primenet Services for the Internet [phone]

In article <[e-mail]> you wrote:
: Hello everyone,

: I've recently begun to try to pick up some Mac programming.  I've got a
: few of the Inside Mac books, as well as Dave Mark's book, and have gone
: through the examples.  This toolbox stuff is driving me buggy!  There is
: so much to understand, I have become overwhelmed to the point that it
: seems like a mammoth undertaking to even try a *small* mac project.  Even
: printing an error message takes a major effort.  Required AppleEvents,
: proper preference files, being background friendly...you see my point.

I'm a newbie also at programming the Mac.  But I'm a veteran with the
IIGS so I am use to using a toolbox.  I suggest you get Inside Mac on CD
if you have a CD drive.  Or if you have enough memory on a hard drive you
can down load it.  It takes a while to get used to the DOCViewer but
its easier after a while.  I also suggest you get an introductory Mac
programming book from the book store.

: So, what advice can you veterans out there give to
help me get up to : speed?  A few ideas that I have thought of are:

: Any pointers will be gratefully gulped down.  I can't be the only one out
: here that has become frustrated with the daunting task of trying to master
: the toolbox.

In a few hours I'm going to upload my first attemp to my FTP site (listed
in sig below).  It was written with CodeWarrior.  I'm also uploading the
source code.  Let me know if this helps you. And anybody looking at the
source all comments are welcome.  Especially "Why did you do that when
this would have been better".

The file name is ASCII.Helper.S.bsc in path /users/c/clay1/applemac

--
Clay

NOTE! Opinions will change due to new information.
|--------------------------------------------------------------------|
|Effective Software Solutions   Clayburn W. Juniel, III              |
|Custom Software Design         1928 E. Camelback Rd. #623           |
|Phone:     [phone]       Phoenix, AZ   85016-4143   USA       |
|Fax:       [phone]                                            |
|Internet:  [e-mail]  WWW:  http://www.primenet.com/~clay1 |
|           [e-mail]  FTP:  ftp.primenet.com  users/c/clay1|
|--------------------------------------------------------------------|


+++++++++++++++++++++++++++

>From [e-mail] (Tony Wingo)
Date: Fri, 16 Jun 1995 00:57:37 GMT
Organization: Apple Computer

In article <ellens-0606950857210001@47.128.6.6>, [e-mail] (Chris
Ellens) wrote:

> In article <[e-mail]>,
> [e-mail] (Scott Taschler) wrote:
>
> ] Hello everyone,
> ]
> ] I've recently begun to try to pick up some Mac programming.  I've got a
> ] few of the Inside Mac books, as well as Dave Mark's book, and have gone
> ] through the examples.  This toolbox stuff is driving me buggy!  There is
> ] so much to understand, I have become overwhelmed to the point that it
> ] seems like a mammoth undertaking to even try a *small* mac project.  Even
> ] printing an error message takes a major effort.  Required AppleEvents,
> ] proper preference files, being background friendly...you see my point.
> ]
> ] So, what advice can you veterans out there give to help me get up to
> ] speed?  A few ideas that I have thought of are:
> ]
> ] o  Finding a good library out there that provides the basic framework for
> ] an application, so I can just fill in the unique details of my app
> ]
> ] o  A good toolkit to isolate some of the complications of the toolbox?
> ] (ala Tcl/Tk in the UNIX world.)
> ]
> ] o  Perhaps a good class library is what I need.  TC++ has the Visual
> ] Architect, which looks promising, but the Think Class Library is hardly
> ] any more simple than the standard toolbox, is it?
> ]
> ] Any pointers will be gratefully gulped down.  I can't be the only one out
> ] here that has become frustrated with the daunting task of trying to master
> ] the toolbox.
>

I missed the orignal part of this thread, but I would strongly recommend

"Macintosh Programmiing Secrets, 2nd. Ed" by Scott Knaster and Keith Rollin.
pub my Addison-Wesley (ISBN 0-201-58134-5)

They do you a real nice job of walking you through the construction of a
(C-based) framework one step at a time, discussing why they're doing what
they're doing at each step. Given the amount of material these guys cover,
this book is much less daunting than most I've seen. The fact that thye
both did time in Apple's Developer Technical Support Group doesn't hurt
either.

--
-tony

>>usual disclaimer<<

+++++++++++++++++++++++++++

>From [e-mail] (Dale M Greer)
Date: 16 Jun 1995 04:52:58 GMT
Organization: The University of Texas at Dallas

Paul DuBois ([e-mail]) wrote:
> From article <3rlshq$[e-mail]>, by [e-mail] (Dale M Greer):
> > [...TransSkel has...]
> > projects in three flavors: MPW, THINK, and Metrowerks.

> Which version of TransSkel is this?  Bob's?  The standard version
> (currently at release 3.20) is usable from THINK C (68K), Symantec
> C++ (PPC), Metrowerks C (68K or PPC) and THINK Pascal -- i.e., no
> MPW projects.  Release 3.21 will drop THINK Pascal support in favor
> of Metrowerks Pascal (68K or PPC) support.

Doh!  Guess I should have checked before I said it had an MPW project.

--

Dale Greer, [e-mail]
"I'm tryin' ta think, but nutt'n happens!" - Curley


+++++++++++++++++++++++++++

>From [e-mail] (Bob Hillier)
Date: 16 Jun 1995 17:33:35 GMT
Organization: Bell-Northern Research Ltd.


In article <[e-mail]>, [e-mail] (Tony Wingo) writes:
|> I missed the orignal part of this thread, but I would strongly recommend
|>
|> "Macintosh Programmiing Secrets, 2nd. Ed" by Scott Knaster and Keith Rollin.
|> pub my Addison-Wesley (ISBN 0-201-58134-5)
|>

This book is quite good except that some of the example code is
*NOT* included in the book. A terse description of the kind of
changes required for a particular section is provided and I have
not quite figured out what the description really means. I am an
experienced UNIX C/C++ programmer but new to the MAC
environment.

Anyways... I know that the source code is available on a disk
from the publisher but that means I wait 3-4 weeks if I order
it. Does anyone have a softcopy or know where I can get a
softcopy of the source? (I am not trying to avoid paying the
publisher, I just want to continue working through the example).
As well, typing the source in is pretty much a drag and I
*really* want a softcopy if I can find it.

thanks
bob



---------------------------

>From [e-mail] (Alex Metcalf)
Subject: Time manager callback without asm?
Date: Sun, 11 Jun 1995 00:02:20 GMT
Organization: The Twilight Zone


Hey everyone,

        I've been doing a bit of code tidying up in preparation for
recompiling for Power Macs. So... some of my code involves a time callback
whereby the TMTaskPtr (or whatever it is) is passed to the callback in
register A1.

        Having scanned through the Universal Headers, it appears that I
need some form of glue, and perhaps the use of a UPP. However, even though
I got the Universal Headers with SC++ 7, I received zero information in
the documentation about how to use them. Exactly how do I set up a Time
Manager callback to read A1 _without_ using asm, and probably using some
new glue stuff? It would always help if I knew exactly what a UPP is, but
as I said, I haven't got any docs on it.

        Thanx,





        Alex

--
Alex Metcalf             Windows 95: Just another
[e-mail]        pane in the glass.

http://www.fen.bris.ac.uk/students/am4001/


+++++++++++++++++++++++++++

>From [e-mail] (Jump Long)
Date: 11 Jun 1995 03:23:43 -0400
Organization: America Online, Inc. (1-800-827-6364)

Alex Metcalf writes:
>I've been doing a bit of code tidying up in preparation for recompiling
>for Power Macs. So... some of my code involves a time callback whereby
>the TMTaskPtr (or whatever it is) is passed to the callback in register
>A1.
>
> Having scanned through the Universal Headers, it appears that I need
>some form of glue, and perhaps the use of a UPP. However, even though I
>got the Universal Headers with SC++ 7, I received zero information in
>the documentation about how to use them. Exactly how do I set up a Time
>Manager callback to read A1 _without_ using asm, and probably using some
>new glue stuff? It would always help if I knew exactly what a UPP is,
>but as I said, I haven't got any docs on it.

Alex, for a simple example of a Time Manager task that compiles for both
CFM and non-CFM (classic 68K), see the function TimeOutTask in the file
Search.c in Apple's MoreFiles sample code. The code shows how to
conditionally build your code to work either way using #if GENERATINGCFM
and how to use the NewTimerProc macro to get a UPP to pass in tmAddr.

- Jim Luther

---------------------------

>From [e-mail] (Paul DuBois)
Subject: TransSkel 3.21 is available (MW Pascal support added)
Date: 16 Jun 1995 14:18:18 -0500
Organization: Castra Parvulorum

Release 3.21 of TransSkel, a skeleton for Macintosh application development
under MetroWerks C or Pascal or Symantec C++/THINK C, is now available.

This is an update release; it provides support for Metrowerks Pascal (68K or
PPC) and NO LONGER provides support for THINK Pascal.  The 3.21 release
notes provide details on the reasons for this decision.  I have only tried
using TransSkel with MW Pascal from CodeWarrior 6/6.1, although I'd expect
it to work with earlier CW releases.

As before, TransSkel still compiles under MetroWerks C (PPC or 68K), as well
as Symantec C++ (PPC) and THINK C (68K).

TransDisplay 3.10 and TransEdit 3.10 are also available now, and have been
updated in similarly.  TransDisplay and TransEdit are modules that can be
dropped into TransSkel-based projects to provide display-only or editable
text windows.

TransSkel, TransDisplay, and TransEdit are available via any of the following:

anonymous ftp to ftp.primate.wisc.edu (under /pub/mac/TransSkel)

gopher to gopher.primate.wisc.edu, then select "Primate Center Software
Archives")

WWW using URL http://www.primate.wisc.edu/software/mac/TransSkel/.

TransSkel 3.20, TransDisplay 3.09, and TransEdit 3.09 are the last release
to retain THINK Pascal support.  They will remain on the archive site
indefinitely.
--
Paul DuBois
[e-mail]

"I'm going to learn worm-talk next," said Janetta  -- Grandaddy's Place

---------------------------

>From [e-mail] (Rene Ros)
Subject: Uppercase Command Keys?
Date: Thu, 15 Jun 1995 19:49:35 GMT
Organization: NIKHEFK

Hi,

I've been struggling with the code listed in IM Text on page C-24 to
have uppercase Command key equivalents. I.e. I need to be able to get
the character code for a question mark, which means most of the time the
shift key shouldn't be ignored.

Is there a mistake in the sample code in IM Text? Or am I doing something
wrong? Does someone have some C code which does the same? Perhaps I've
been juggling with the bit operators? :-)

Thanks in advance,
Rene

PS. Please post and remail your reply. The newshost at my usual site
    (bio.vu.nl) is acting up weird. You can email to the address listed
    in the header or to [e-mail]. Thanks!


+++++++++++++++++++++++++++

>From [e-mail] (Ari Halberstadt)
Date: Sat, 17 Jun 1995 04:01:01 -0400
Organization: North Shore Access/Eco Software, Inc; ([e-mail])

In article <[e-mail]>,
[e-mail] (Rene Ros) wrote:

>Hi,
>
>I've been struggling with the code listed in IM Text on page C-24 to
>have uppercase Command key equivalents. I.e. I need to be able to get
>the character code for a question mark, which means most of the time the
>shift key shouldn't be ignored.
>
>Is there a mistake in the sample code in IM Text? Or am I doing something
>wrong? Does someone have some C code which does the same? Perhaps I've
>been juggling with the bit operators? :-)

      ...
      key = (macevent->message & keyCodeMask) >> CHAR_BIT;
      key = (wsKeyUsingModifiers(key, 0) & charCodeMask);
      menu = MenuKey(key);
      ...

/* wsKeyUsingModifiers returns the key code (virtual and ascii codes)
   that would be generated from typing the given key code and modifiers.
   You can get the key code from the event message for a keyDown event
   by using keyCodeMask and shifting the result right by CHAR_BIT. This
   function is useful for detecting command-key combinations using
   additional modifiers. */
long wsKeyUsingModifiers(unsigned char code, unsigned short modifiers)
{
   UInt32   state = 0;  /* state for KeyTranslate */
   Ptr      kchr;       /* current 'KCHR' */

   kchr = (Ptr) GetScriptManagerVariable(smKCHRCache);
   return(KeyTranslate(kchr, ((modifiers & 0xff00) | code), &state));
}

--
Ari Halberstadt  [e-mail]  (formerly [e-mail])
And yet, there was only one great thing. / To live. / To See. / In hunts and on journeys / the great day that dawns / and the light that fills the world. -- Inuit, from "500 Nations".

---------------------------

>From [e-mail] (Lkw)
Subject: [Q] Drag and Drop Mgr hilighting
Date: 2 Jun 1995 00:25:35 -0400
Organization: America Online, Inc. (1-800-827-6364)

Anybody know what RGBColors (foregound and background), PenPat, and
PenMode Apple uses to highlight in the Drag and Drop Manager?  I need to
directly update and manipulate areas that the Drag Manager highlights, and
therefore need to use the same colors and modes so that when the Drag Mgr
decides to un-highlight, the border will return to normal.

+++++++++++++++++++++++++++

>From [e-mail] (Brian L. Matthews)
Date: 3 Jun 1995 06:51:40 GMT
Organization: Northwest Nexus, Inc. - Professional Internet Services

In article <3qm3rv$[e-mail]>, Lkw <[e-mail]> wrote:
|Anybody know what RGBColors (foregound and background), PenPat, and
|PenMode Apple uses to highlight in the Drag and Drop Manager?

It uses HiliteMode, which is described pretty well in Inside Mac.

|update and manipulate areas that the Drag Manager highlights, and
|therefore need to use the same colors and modes so that when the Drag Mgr
|decides to un-highlight, the border will return to normal.

I suggest looking at UpdateDragHilite.  It's designed for just this case.

Brian

+++++++++++++++++++++++++++

>From [e-mail] (Scott Kevill)
Date: Sun, 04 Jun 1995 23:04:36 -0700
Organization: The University of Western Australia

In article <3qp0ps$[e-mail]>, [e-mail] (Brian
L. Matthews) wrote:

> In article <3qm3rv$[e-mail]>, Lkw <[e-mail]> wrote:
> |Anybody know what RGBColors (foregound and background), PenPat, and
> |PenMode Apple uses to highlight in the Drag and Drop Manager?
>
> It uses HiliteMode, which is described pretty well in Inside Mac.
>
> |update and manipulate areas that the Drag Manager highlights, and
> |therefore need to use the same colors and modes so that when the Drag Mgr
> |decides to un-highlight, the border will return to normal.
>
> I suggest looking at UpdateDragHilite.  It's designed for just this case.
>
> Brian

This is incorrect, the Drag Manager does not use HiliteMode, it uses the
tinge colours for windows set in the Color control panel. Try it and see.

There is a DTS snippet (toolbox/GetDragHiliteColor or something) that
calculates the correct colour to draw with. However it doesn't handle the
situation for b&w, which is simply a 50% gray pattern. This is not
guaranteed to stay the same in the future, because it is undocumented.

Hope this helps,

Scott Kevill
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Lawrence D9Oliveiro)
Date: Wed, 07 Jun 1995 17:33:03 +1200
Organization: University of Waikato

In article <[e-mail]>,
[e-mail] (Scott Kevill) wrote:

>In article <3qp0ps$[e-mail]>, [e-mail] (Brian
>L. Matthews) wrote:
>
>> In article <3qm3rv$[e-mail]>, Lkw <[e-mail]> wrote:
>> |Anybody know what RGBColors (foregound and background), PenPat, and
>> |PenMode Apple uses to highlight in the Drag and Drop Manager?
>>
>> It uses HiliteMode, which is described pretty well in Inside Mac.
>>
>> |update and manipulate areas that the Drag Manager highlights, and
>> |therefore need to use the same colors and modes so that when the Drag Mgr
>> |decides to un-highlight, the border will return to normal.
>>
>> I suggest looking at UpdateDragHilite.  It's designed for just this case.
>>
>> Brian
>
>This is incorrect, the Drag Manager does not use HiliteMode, it uses the
>tinge colours for windows set in the Color control panel. Try it and see.

Yes, but I think it's using that colour with HiliteMode. How do I know? I
had some code that, after calling ShowDragHilite and accepting the drag,
was causing the window to be erased in its drag receive handler. Naturally
this wiped the drag highlight; then when I called HideDragHilite in the
track-drag handler to turn off the highlight before cleaning up, the
highlight appeared again!

+++++++++++++++++++++++++++

>From [e-mail] (Brian L. Matthews)
Date: 7 Jun 1995 18:10:37 GMT
Organization: Northwest Nexus, Inc. - Professional Internet Services

In article <[e-mail]>,
Scott Kevill <[e-mail]> wrote:
|In article <3qp0ps$[e-mail]>, [e-mail] (Brian
|L. Matthews) wrote:
|> It uses HiliteMode, which is described pretty well in Inside Mac.
|This is incorrect, the Drag Manager does not use HiliteMode, it uses the
|tinge colours for windows set in the Color control panel. Try it and see.

Right you are.  Apple's documentation is somewhat misleading here.  Near
the bottom of page 13 in the Drag and Drop Human Interface Guidelines,
it says "In the case of color, the frame is drawn in Color Quickdraw's
hilite mode."  However, the previous sentence (which I managed to forget
when I posted my first followup :-)) reads "The Drag Manager draws the
frame in a color based on the window color specified in the Colors control
panel."  So it does use hilite mode, it just uses the window color instead
of the hilite color.

|There is a DTS snippet (toolbox/GetDragHiliteColor or something) that
|calculates the correct colour to draw with. However it doesn't handle the
|situation for b&w, which is simply a 50% gray pattern. This is not
|guaranteed to stay the same in the future, because it is undocumented.

Do you mean the 50% gray pattern isn't documented, or the DTS snippet?
The 50% gray pattern is documented, again on page 13.

Brian

+++++++++++++++++++++++++++

>From Simon Fraser <[e-mail]>
Date: 8 Jun 1995 20:34:41 GMT
Organization: NERC Centre for Population Biology, Imperial College

[e-mail] (Brian L. Matthews) wrote:
>In article <[e-mail]>,
>Scott Kevill <[e-mail]> wrote:
>|In article <3qp0ps$[e-mail]>, [e-mail] (Brian
>|L. Matthews) wrote:
>|> It uses HiliteMode, which is described pretty well in Inside Mac.
>|This is incorrect, the Drag Manager does not use HiliteMode, it uses the
>|tinge colours for windows set in the Color control panel. Try it and see.
>
>Right you are.  Apple's documentation is somewhat misleading here.  Near
>the bottom of page 13 in the Drag and Drop Human Interface Guidelines,
>it says "In the case of color, the frame is drawn in Color Quickdraw's
>hilite mode."  However, the previous sentence (which I managed to forget
>when I posted my first followup :-)) reads "The Drag Manager draws the
>frame in a color based on the window color specified in the Colors control
>panel."  So it does use hilite mode, it just uses the window color instead
>of the hilite color.
>
>|There is a DTS snippet (toolbox/GetDragHiliteColor or something) that
>|calculates the correct colour to draw with. However it doesn't handle the
>|situation for b&w, which is simply a 50% gray pattern. This is not
>|guaranteed to stay the same in the future, because it is undocumented.
>
>Do you mean the 50% gray pattern isn't documented, or the DTS snippet?
>The 50% gray pattern is documented, again on page 13.

Have you folks seen the technote?

   http://www.info.apple.com/dev/technotes/Toolbox/tb_33.html

This has some stuff about custom window colours and the drag hilite
colour, which might solve the problems.

_________________________________________________________________
Simon Fraser                   NERC Centre for Population Biology
[e-mail]                Imperial College at Silwood Park
                                       Ascot, Berks.  SL5 7PY  UK


+++++++++++++++++++++++++++

>From [e-mail] (Scott Kevill)
Date: Sat, 10 Jun 1995 13:45:02 +0800
Organization: The University of Western Australia

In article <3r4q2t$[e-mail]>, [e-mail] (Brian
L. Matthews) wrote:

> In article <[e-mail]>,
> Scott Kevill <[e-mail]> wrote:
>
> |There is a DTS snippet (toolbox/GetDragHiliteColor or something) that
> |calculates the correct colour to draw with. However it doesn't handle the
> |situation for b&w, which is simply a 50% gray pattern. This is not
> |guaranteed to stay the same in the future, because it is undocumented.
>
> Do you mean the 50% gray pattern isn't documented, or the DTS snippet?
> The 50% gray pattern is documented, again on page 13.
>
> Brian

Sorry for the confusion.

I meant the method for obtaining the colour is not documented, and this
warning is also given in the snippet. I also meant that the snippet works
properly only in colour, it does not draw the 50% gray in b&w when perhaps
it should.

Hope this clears things up.

Scott.

--

Scott Kevill
[e-mail]

---------------------------

>From [e-mail] (David Phillip Oster)
Subject: [Q] How to tell if a hard disk is removable
Date: Thu, 8 Jun 1995 01:00:28 GMT
Organization: Netcom Online Communications Services (408-241-9760 login: guest)


The Memory control panel gives you a pop-up menu of hard disks for setting
the location of a virtual memory swap file. It does not include removable
hard disks. How does it know?

More generally, how do you tell if a hard disk is removable?
--
- ------- <mail-to:[e-mail]> ----------
Ahh! The thorazine is wearing off and the odinazine is coming on...

+++++++++++++++++++++++++++

>From Alex Rosen <[e-mail]>
Date: 8 Jun 1995 13:34:47 GMT
Organization: Pro CD, Inc.

In article <[e-mail]> David Phillip Oster,
[e-mail] writes:
>More generally, how do you tell if a hard disk is removable?

This is some code that I copied from John Norstad's Disinfectant source.
It's probably in MoreFiles, too (everything else is).
--Alex

/* Returns true if the volume is ejectable. */
Boolean IsEjectable (short vRefNum)
{
        HParamBlockRec  pBlock;                         /* vol info param block */
        short                   driveNum;                       /* driver number of cur vol */
        DrvQEl                  *curDrive;                      /* ptr to current drive queue element */
        OSErr                   rCode;                          /* result code */
        unsigned char   flagByte;                       /* drive queue element flag byte */

        /* Get driveNum = drive number of drive containing volume. */

        pBlock.volumeParam.ioNamePtr = nil;
        pBlock.volumeParam.ioVolIndex = 0;
        pBlock.volumeParam.ioVRefNum = vRefNum;;
        if (( rCode = PBHGetVInfo(&pBlock, false) ) != noErr) return false;
        driveNum = pBlock.volumeParam.ioVDrvInfo;

        /*      Walk the drive queue until we find driveNum.  The second byte in
                the four flag bytes preceding the drive queue element is 8 or $48
                if the drive is nonejectable. */

        curDrive = (DrvQEl*)(GetDrvQHdr())->qHead;
        while (true) {
                if (curDrive->dQDrive == driveNum) {
                        flagByte = *((Ptr)curDrive - 3);
                        return (flagByte != 8 && flagByte != 0x48);
                };
                curDrive = (DrvQEl*)curDrive->qLink;
                if (!curDrive) return false;
        };
}

+++++++++++++++++++++++++++

>From [e-mail] (Byron Han)
Date: Thu, 8 Jun 1995 20:26:59 GMT
Organization: Institute for Astronomy, Hawaii

In article <[e-mail]> [e-mail] (David Phillip Oster) writes:
>
>The Memory control panel gives you a pop-up menu of hard disks for setting
>the location of a virtual memory swap file. It does not include removable
>hard disks. How does it know?
>
>More generally, how do you tell if a hard disk is removable?

There is a bit in the drive queue that tells you if a drive is ejectable
or not.

--
 Byron Han, Graduate Student        University of Hawai`i at Mano`a
 Institute for Astronomy                 Email: [e-mail]
 Quote: "Given current global population growth rates, reproduction
                  will soon no longer be a right but a priviledge."

---------------------------

End of C.S.M.P. Digest
**********************